IBIS Macromodel Task Group

Meeting date: 25 October 2022

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Cadence Design Systems:     * Ambrish Varma
                              Jared James
Google:                       Hanfeng Wang
                              GaWon Kim
Intel:                      * Michael Mirmak
                            * Kinger Cai
                              Chi-te Chen
                              Alaeddin Aydiner
Keysight Technologies:        Fangyi Rao
                              Majid Ahadi Dolatsara
                              Ming Yan
                              Radek Biernacki
                              Rui Yang
Luminous Computing            David Banas
Marvell                       Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Mike LaBonte
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
Missouri S&T                  Chulsoon Hwang
                              Yifan Ding
Rivos                         Yansheng Wang
SAE ITC                       Michael McNair
Siemens EDA (Mentor):       * Arpad Muranyi
Teraspeed Labs:             * Bob Ross
Waymo:                        Zhiping Yang
Zuken USA:                  * Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- Arpad noted that he had removed Chulsoon's Pre-driver PSIJ Sensitivity BIRD
  from the agenda because the BIRD had been officially submitted.
  
- Bob asked whether we should cancel the next week's meeting because of the
  upcoming Asian IBIS Summits, but the group decided not to cancel.

-------------
Review of ARs:

- Arpad to send out draft0.4 of the clock_times clarification BIRD.
  - Done.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the October 18th
meeting.  Michael moved to approve the minutes.  Ambrish seconded the motion.
There were no objections.

--------------
New Discussion:

clock_times clarification BIRD draft:

Arpad had prepared a presentation to illustrate the issue for which he and
Fangyi had added the language:

  The smallest clock time value in the clock_times vector shall never be smaller
  than the starting time of the waveform segment in each AMI_GetWave call.
  
Arpad's presentation showed clock and data waveforms and illustrated clock times
returned by the DQS model when Rx_Use_Clock_Input is set to "Times" in the
corresponding DQ model.  Arpad first focused on the case in which the DQS model
returned a clock time at the end of one block that was shifted right, i.e.,
delayed, so that it actually corresponded to the next block of data waveform.
He said this case was not problematic, since the EDA tool or DQ model could
buffer the clock time(s) for use with subsequent blocks of data.

Arpad then illustrated a case in which the first clock time returned by the DQS
model had been shifted left, i.e., advanced so that it corresponded to the
previous block of waveform data.  Arpad said this was the problematic case that
caused the "causality" issue because the previous block of data had already
been processed.  The DQ model, for example, already had to process and return
the previous block of data waveform.  So, buffering wouldn't solve the problem.

Walter asked whom we are prohibiting from doing something with this language.
Arpad said the language is telling the model maker not to return a clock time
value smaller than the starting time of the block of waveform data.  Walter
said the language is unnecessary.  He said the model maker is responsible for
making their DQS and DQ models work together.  The EDA tool can't do anything
about it anyway.  All the EDA tool does is move the clock_times output of the
DQS model into the clock_times input of the DQ model (in the "Times" case).

Walter gave an example of a block of data made up entirely of zeros except for a
single lonely one at the end of the block.  In general, that lonely one will
come back with the next GetWave call.  Walter said the amount of delay depends
upon the filter.  Say you have a 4 tap DFE, and your first block of data
waveform corresponds to 100 bits.  The returned waveform  might only have used
96 of the input bits, with the last four not appearing until the return of the
next GetWave call.  The model would know to buffer as many bits from the first
call (e.g., 4 in this case) as necessary for processing at the beginning of the
second call.  So, the DQS model could return clock times corresponding to the
last 4 bits of the first block of waveform data when it processed the second
block of waveform data.

Walter acknowledged that models probably wouldn't be shifting the returned clock
times into previous blocks anyway, but he said there's no reason to introduce
this language and restrict the model maker.  He said the only thing we have to
state is that the EDA tool takes the output clock times from the DQS (Clock)
model and passes them into the DQ (Data) model.  Randy said the specification
already does that.  Walter and Randy agreed that the other portions of this new
proposal from Arpad are helping clarify the requirements.

Arpad said he would rethink the need for this statement restricting the clock
times values returned.  He asked everyone to provide their thoughts and comments
via the email reflector. 

- Ambrish: Motion to adjourn.
- Bob: Second.
- Arpad: Thank you all for joining.

    
-------------
Next meeting: 01 November 2022 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
